Reject CR/LF and obs-fold in OCSP requests#10966
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request hardens the OpenSSL-compatibility OCSP request builder against HTTP request splitting by rejecting CR/LF and header obs-fold patterns in caller-supplied request components, aligning behavior with OpenSSL and existing wolfSSL URL decoding safeguards.
Changes:
- Reject CR/LF anywhere in OCSP URLs parsed via
wolfSSL_OCSP_parse_url(). - Reject CR/LF in OCSP request line pieces (
op,path) and in headername/value, and reject header names starting with SP/HTAB (obs-fold). - Add regression tests covering CR/LF and obs-fold injection attempts.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/api.c | Adds negative tests to ensure CR/LF and obs-fold inputs are rejected in OCSP URL parsing and request/header building. |
| src/ssl.c | Adds early CR/LF rejection in wolfSSL_OCSP_parse_url() to prevent tainted host/path/port outputs. |
| src/ocsp.c | Adds shared CR/LF validation helper and enforces CR/LF + leading SP/HTAB rejection in OCSP request building APIs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ejohnstown
force-pushed
the
upd-ocsp
branch
2 times, most recently
from
July 22, 2026 21:48
c514320 to
a50e939
Compare
The OpenSSL compatibility APIs copied caller-supplied strings into the outbound OCSP request verbatim, so an embedded newline split it into attacker-chosen header lines, and a header name starting with SP or HTAB folded into the preceding header's value. OpenSSL rejects these; the library's own fetch path already rejects CR/LF via wolfIO_DecodeUrl(). * wolfSSL_OCSP_REQ_CTX_http(): reject CR/LF in op and path. * wolfSSL_OCSP_REQ_CTX_add1_header(): reject CR/LF in name and value. * wolfSSL_OCSP_REQ_CTX_add1_header(): reject a name starting with SP or HTAB, which RFC 7230 Section 3.2.4 treats as an obs-fold continuation of the previous header rather than a new header. * wolfSSL_OCSP_parse_url(): reject CR/LF anywhere in the URL, the likely source of a tainted path via a certificate's AIA extension.
JacobBarthelmeh
approved these changes
Jul 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The OpenSSL compatibility APIs copied caller-supplied strings into the outbound OCSP request verbatim, so an embedded newline split it into attacker-chosen header lines, and a header name starting with SP or HTAB folded into the preceding header's value. OpenSSL rejects these; the library's own fetch path already rejects CR/LF via wolfIO_DecodeUrl().
Issue: ZD-21992
Testing
Added test cases for the change.
Checklist